QUESTION:
I have a customer with two risc systems that are having telnet sessions
that time out and connect intermittently. One machine at 3.2.4 and the
other at 3.2.5. Everything worked fine for two weeks. Also the com-
munications is token ring.
---------- ---------- ---------- --------- ---------- ----------
A: From the text of your question, it is difficult to determine what
may be causing the telnet sessions to only connect intermittently.
To help assist in matters, I have appended two documents below that
I believe may be beneficial to resolving the problem.
The first document is called "Telnet Problem Determination" and the
second is "TCP/IP Problem Determination". I will library this item
for future use.
If this information fails to resolve the problem, please append with
as much specific information as possible to help with the resolution.
----------------------------------
Telnet Problem Determination
----------------------------
1 - Verify the base TCP/IP configuration. See tcpippd.txt.
2 - Verify that the telnet is a subserver of inetd. Use the
command "inetserv -sIX" or "smit inetdconf"..."List All inetd
Subservers". If telnet is not listed, add it using the
command "smit inetdconf"..."Add an inetd Subserver".
3 - Verify that you can telnet to your own IP address. If you
can't, the base TCP/IP configuration is incorrect.
4 - If another host can't telnet into this RISC, run an iptrace
and verify that this RISC is actually receiving the connection
request. Specify the "-p 23" flag when you run the iptrace.
The following two packets illustrate what to look for:
=====( packet received on interface en0 )=====Mon Mar 14 14:20:28 1994
ETHERNET packet : . 02:60:8c:2e:bb:11 -> 02:60:8c:2f:31:4e . type 800
(IP)
IP header breakdown:
< SRC = 9.3.6.32 > (u2e.austin.ibm.com)
< DST = 9.3.6.35 > (festere.austin.ibm.com)
ip_v=4, ip_hl=20, ip_tos=0, ip_len=44, ip_id=44727, ip_off=0
ip_ttl=60, ip_sum=b1cc, ip_p = 6 (TCP)
TCP header breakdown:
th_seq=2a2e3401, th_ack=0
th_off=6, flags
th_win=65535, th_sum=16c3, th_urp=0
00000000 020405b4 |.... |
=====( packet transmitted on interface en0 )=====Mon Mar 14 14:20:28 1994
ETHERNET packet : . 02:60:8c:2f:31:4e -> 02:60:8c:2e:bb:11 . type 800
(IP)
IP header breakdown:
< SRC = 9.3.6.35 > (festere.austin.ibm.com)
< DST = 9.3.6.32 > (u2e.austin.ibm.com)
ip_v=4, ip_hl=20, ip_tos=0, ip_len=44, ip_id=53448, ip_off=0
ip_ttl=60, ip_sum=8fbb, ip_p = 6 (TCP)
TCP header breakdown:
th_seq=9b51c201, th_ack=2a2e3402
th_off=6, flags
th_win=16060, th_sum=7aa2, th_urp=0
00000000 020405b4 |.... |
Notice the "destination port" and "th_ack" fields in the TCP header
breakdown of packet 1. port=23 indicates that this packet is telnet
related. th_ack=0 indicates this is the first packet in the telnet
connection, and so it is the telnet request. th_ack=2a2e3402 in
packet 2 confirms that festere acknowledged u2e's telnet connection
request.
5 - Obtain a trace of all the data sent on the telnet connection.
The trace will be in hexadecimal, and hence very difficult to
interpret. Only use this option when all other avenues of PD
fail to identify the problem:
a) At the shell prompt, enter "telnet -n telnet.out".
b) At the telnet prompt, enter "toggle netdata".
c) At the telnet prompt, enter "open "
Continue with the telnet connection until you have recreated the
error. Then, exit out of telnet. The file telnet.out will
contain an exhaustive log in hexadecimal of everything sent and
received on the telnet connection (i.e. AFTER the TCP connection
has been established and the telnet options negotiated).
-----------------------
Contents
--------
TCP/IP Problem Determination
How to do PD
Common Questions
Common Error Messages
Other Diagnostic Tools
TCP/IP Problem Determination
----------------------------
TCP/IP problem determination (PD) is the process of finding out as
quickly as possible why a TCP/IP configuration is not working. Once
you know why the configuration is not working, you instantly know
what you need to do to fix it.
How to do PD
------------
Step 1: Draw a picture
Effective problem solvers always draw a picture. Sometimes,
experienced problem solvers do not actually put the picture on paper,
but they still draw a picture mentally. A picture reveals the
relationships between objects, and the attributes of those objects.
Since you want to do PD as quickly as possible, it is most
efficient to know ahead of time what symbols to use. In networking,
with just six symbols you can draw a wide variety of useful
pictures. You should know how to draw an Ethernet, a Token Ring,
a FDDI ring, dial-up connection, a mainframe channel attachment,
and a network station. Here is how these symbols commonly appear:
NS (Network Station)
Ethernet __|__________
|
NS
______
Token Ring NS ___| |___ NS
|______|
==========
FDDI Ring NS ---|| ||--- NS
==========
Dial up NS --------//-------- NS
Mainframe channel attachment NS ================== NS
.-------.
Network Station NI ---| |--- NI (Network
`-------' Interface)
Legend of Commonly Used Symbols
The symbols you draw depend on the problem description you
have. Begin with the symbol for the type of network, and
then add the network stations. The symbol for the network should
have one line attached to it for each network station (e.g. the
lines connecting the letters "NS" to the network symbols, as shown in
the legend above). A network station can be a RISC, a mainframe, a
router, a PC, etc.
Step 2: Label the picture
From the information given in the problem description, label
all the network stations with the hostname, IP address, and
netmask. If a network station has multiple interfaces (as shown
in the legend above), label each interface completely, including
the interface name (e.g. "en0", "tr1", etc.).
Step 3: Verify the base configuration.
All TCP/IP functionality (name resolution, telnet, the r* commands,
FTP, NFS, NIS, etc...) relies on correct configuration of the
adapter, network interface, and routing table. An easy way to
verify the base configuration is to ping another host (which you
know is working correctly) by its IP address. If the ping succeeds,
then you know that the base configuration is correct.
If the ping does not succeed, there are several possible sources
of the problem: (1) incorrect software configuration, (2) incorrect
adapter configuration or faulty adapter, (3) network problem.
First, check the software configuration:
Q1) Are the IP addresses valid and consistent across all the hosts
in the IP subnet? Use the "ifconfig " command.
Q2) Are the netmasks the same on each host in the IP subnet? Use
the "ifconfig " command.
Q3) Is the interface up? Use the command "ifconfig " and
look for the flags UP and RUNNING.
Q4) Is the routing table correct? Use the the "netstat -rn" command
and look for (1) a route to localhost, (2) a route to this host's
IP subnet, and (3) a default route out of this host's IP subnet.
If the routing table is incorrect, use the "smit route" command
to add/remove the appropriate routes.
Q5) Is inetd running? Use the "lssrc -s inetd" command. If not,
use the command "startsrc -s inetd" to start it. Or, use
"smit inetd"..."inetd Subsystem".
Next, check the adapter configuration. See adapterpd.txt
Finally, check the network itself:
Q1) Is there are router or gateway between this host and the
remote host? If so, is it configured correctly? I.e. can
other machines on this physical segment and IP subnet
communicate with the outside world using that router/gateway?
Q2) Is there a break in the cabling somewhere? Is the Ethernet
terminated properly? (This is an area which requires the
involvement of a CE or an electrical engineer. It is beyond
the scope of AIX configuration.)
Once the base configuration is correct, you can proceed with
PD specific to a particular application, such as name service (DNS
and NIS), etc. See: iptrace.txt, nfspd.txt, nispd.txt
Common Questions
----------------
Q) How can I have two different IP subnets on the same physical Token
Ring (or Ethernet) segment?
A) Install a second network adapter and define an interface for it.
Specify the appropriate IP address and netmask.
Q) How can I have two adapters (interfaces) on the same IP subnet and
the same physical Token Ring (or Ethernet) segment? Will this
improve performance?
A) This is a violation of TCP/IP architecture. In other words, it is
invalid for a machine to have two IP addresses on the same IP subnet.
However, it is possible to configure this, but doing so requires
the following kludge: in order to direct traffic over the second
adapter, you must specify as many host-specific routes as there
are hosts which will use that interface. Use the command:
route add -host <2nd_ip_addr> -netmask
-interface
Q) Can I use en0 and et0 concurrently on the same Ethernet adapter?
A) Yes. Each interface should have a unique IP address on different
IP subnets. Also, you may need to explicitly execute the command
"route add -net -netmask -interface"
in order to define a route to the second subnet.
Q) I have a RISC acting as a router between two different subnets. I
can ping hosts on both subnets, but hosts on network A cannot ping
hosts on network B. Suggestions?
A) Verify that you have IP forwarding turned on (use the "no -a"
command). If ipforwarding has the value "0" (off), then use the
command "no -o ipforwarding=1" to turn IP forwarding on. By default,
IP forwarding is "1", so it may be the case that someone added a
command to the end of the /etc/rc.tcpip file to turn IP forwarding
off.
Q) How can I determine which routes are defined in the ODM and which
are defined dynamically?
A) The OS maintains the kernel routing table in memory. The route to
localhost and the route to the machine's own IP subnet are added
to the routing table based on the definition of the network
interface (e.g. tr0, en0). Static routes are added to the routing
table based on route definitions in the ODM. To see the routes
which are stored in the ODM, use the command:
odmget -q "name=inet0 and attribute=route" CuAt
Q) How do I determine my machine's hostname?
A) Use the "hostname" command. SMIT executes this command when you
execute "smit hostname" and then select "Show the Hostname". The
hostname command retrieves the hostname from the ODM, which you
can do by executing the command:
odmget -q "name=inet0 and attribute=hostname" CuAt
Q: How can I determine that route that a packet takes to a remote
host?
A: Use the "ping -R " command.
Common Error Messages
---------------------
"Error creating listening port"
This error message could be caused by the following:
a) System resource controller daemon (srcmstr) in /etc/inittab is
not running (use the "ps -ef | grep srcmstr " command to check
if the src daemon is running).
To start the daemon verify that the line:
srcmstr:2:respawn:/etc/srcmstr # System Resource Controller
in /etc/inittab is uncommented. If it is not, uncomment it and
then issue the "telinit q" command. Then, verify that the daemon
is running with the command "ps -ef | grep srcmstr".
b) Improperly formatted /etc/services file. The "white space"
separating columns must be tabs, not spaces. You can determine
the type of white space used in the file by issuing the
":set list" command of vi. This command reveals hidden
characters in a file. For example, if you have the line
smtp 25/tcp mail
in /etc/services, the ":set list" command will convert it to
smtp.I.I25/tcp.I.mail $
where
.I (carot I) represents the indent character
$ represents the carriage return/line feed characters
If the ":set list" command converts the line to
smtp 25/tcp mail $
then you will need to delete the spaces and replace them
with tab (indent) characters.
c) The portmap daemon is not running. Verify that the line
start /usr/etc/portmap "$src_running"
in /etc/rc.tcpip is uncommented. If it is not, uncomment it,
and then start the daemon with the command "startsrc -s portmap".
Verify that the daemon is running with the command
"lssrc -s portmap". The output should indicate a status of
"active".
d) You may have a faulty adapter or a loose connection at the
token ring interface. Verify that the cable is firmly attached
to the adapter. Also, use the "diag -a" command to check
your adapter.
Q: When I try to telnet to another RISC, I get the message:
telnet: connect: A remote host refused an attempted connect
operation.
What's wrong?
A: Make sure the inetd daemon is running. Use the command:
"lssrc -s inetd". If it is not running, start it with the command
"startsrc -s inetd", or with "smit inetd"..."inetd Subsystem"..."Start
Using the inetd Subsystem".
Other Diagnostic Tools
----------------------
traceroute - comes with NetView/6000, and with 3.2.4 and later.
NOT available via anonymous ftp at Harpo.seas.ucla.edu
(129.97.2.211)
The following three tools reside in the /usr/local/bin directory of u2e.
They were retrieved via anonymous ftp from burrito.raleigh.ibm.com
in /pub/lantools as the file trtools_315.tar.Z or trtools_32.tar.Z,
depending if you have AIX 3.1.5 or AIX 3.2. Documentation is included.
trp - token ring ping
pra - backwards arp (determine IP address from MAC address)
mcp - microcode ping (lookup microcode level of remote adapter)
-----------------------------------
END OF DOCUMENTS
-----------------------------------
---------- ---------- ---------- --------- ---------- ----------
This item was created from library item Q671544 CVXPL
Additional search words:
COMMUNICATIO CVXPL INTERMITTENT IX OCT94 OZNEW RISCSYSTEM RISCTCP
SESSION SESSIONS SOFTWARE TCPIP TELNET
WWQA: ITEM: RTA000048659 ITEM: RTA000048659
Dated: 04/1996 Category: RISCTCP
This HTML file was generated 99/06/24~12:43:18
Comments or suggestions?
Contact us